Problem

vidu-q2-reference2video and viduq2-pro-fast are the only two Vidu shapes that take reference images as subjects rather than a flat images array. Everything upstream of the gateway speaks image_urls:

• the RouterBase playground renders its upload control only for a model whose schema declares image_urls;
• RouterBase's base64 materialisation and URL pre-check both key on that field.

Net effect: these two models had no way to supply a reference image from the UI at all, and no base64 support via the API. Callers had to hand-write a subjects array and self-host the images.

Change

Accept image_urls for the subject shape too, fanning each URL out into its own subject, in order, so @N addresses the Nth image. An explicit subjects still wins, keeping the richer form (several images of one subject, voice_id) reachable.

Getting the shape right

The enum's doc comment claimed {id|name, images, voice_id} and the existing passthrough test asserted {"id": "@1", …} — both were wrong. That test only checks the blob is forwarded verbatim, so it never exercised the payload against Novita and never caught it.

A live call returned Novita's actual schema:

subjects[]: { "name": string (REQUIRED, "use @{name} in prompt to reference"),
              "images": string[] (max 3),
              "voice_id": string? }

So the key is name, and name is the bare reference — @1 means name: "1", not "@1". Corrected the code, the stale doc comment, and the two tests that encoded the wrong shape.

Verification

• 8/8 vidu_build_body_tests pass, including two new ones (fan-out; explicit-subjects-wins).
• cargo fmt + clippy clean (the one collapsible_if matches the pre-existing images block directly above).
• Live paid generation against Novita via RouterBase: vidu/q2-pro-fast with image_urls → accepted, rendered, MP4 returned. The pre-fix payload was rejected with the 400 quoted above.

🤖 Generated with Claude Code